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INTRODUCTION 


PUR POSE. 

The  purpose  of  Lhis  document  is  to  provide  a  concise  functional  software 
description  ot  Lhe  Mass  Weather  Dissemination  exploratory  Engineering  Model. 

HACK GROUND. 

The  New  York  City  Pilots  Automatic  Telephone  Weather  Answering  Service  (PATWAS) 
test  provided  some  valuable  information  pertaining  to  pilot  acceptance  and  manpower 
savings  of  such  an  automated  system.  A  functional  description  of  the  PATWAS 
system  as  it  existed  in  New  York  City  has  been  excised  from  the  final  report 
No.  FAA-RD-7 7-80 , 1  (reference  1)  and  is  quoted  below. 

"Each  of  the  three  trial  PATWAS  messages  is  composed  of  five  message  segments 
arranged  to  provide  for  rapid  message  update.  Each  segment  is  recorded  on  an 
endless-loop  magnetic  tape  cartridge.  During  the  message  segment  recording 
process,  a  cue  tone  is  placed  immediately  at  the  end  of  each  message  segment. 
The  cue  tone  is  used  to  trigger  the  start  of  the  next  message  segment.  The 
detection  of  the  cue  tone  and  start  of  the  next  message  segment  is  so  rapid  as  to 
be  undetectable  by  the  listener, 

"The  trial  PATWAS  is  an  assemblage  of  data  acquisition  equipment,  studio  quality 
r ec ord i ng/ p l ayback  equipment,  and  telephone  company  equipment.  Briefing  data  are 
acquired  from  the  Weather  Message  Switching  Center  (WMSC)  via  a  110-baud  American 
Standard  Code  for  Information  Interchange  (ASCII)  dedicated  line.  The  data  are 
received  by  a  Haze  I  tine  2000  cathode  ray  tube  (CRT)  terminal  equipped  with  a 
thermal  printer.  Software  changes  made  at  the  WMSC  computers  facilitated  an 
automatic  text  preparation  for  the  update  of  the  various  recordings. 

"Message  segments  are  read  from  a  prepared  script  into  a  microphone.  The  resulting 
utterances  are  recorded  on  a  separate  cartridge  recorder/ pi  aye r .  Immediately  fol¬ 
lowing  the  recording  process,  the  message  segments  are  auditioned  for  content  and 
clarity.  The  updated  message  segment  is  then  manually  loaded  into  the  appropriate 
cartridge  slot  in  the  message  player,  replacing  the  former  segment. 

"Access  to  the  message  player  is  through  the  telephone  company  supplied  barge-in 
equipment.  The  system  operates  as  shown  in  figure  1.  A  pilot  calls  the  appropri¬ 
ate  telephone  number.  If  no  one  else  is  connected  to  the  message  he  has  dialed, 
completion  of  his  call  starts  the  message  at  the  beginning.  From  that  time,  each 
message  segment  is  sequenced  until  he  terminates  the  call.  After  he  hangs  up,  the 
message  will  continue  to  sequence  to  the  end  of  the  last  segment  and  then  stop.  If 
additional  pilots  should  call  while  the  initiating  pilot  is  still  connected  to  the 
system,  the  system  will  continue  to  play  as  long  as  anyone  remains  connected.  As 
described  elsewhere,  pilots  acquiring  the  system  through  the  barge-in  equipment  do 
not  always  get  the  message  at  the  beginning  —  hence  the  term  barge-in." 

The  conclusions  given  at  the  end  of  the  report  on  the  New  York  City  PATWAS  test, 
stated  that  positive  acceptance  of  the  PATWAS  system  among  the  general  aviation 
community  was  indicated  and  a  substantial  decrease  in  the  number  and  length  of 
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Flight  Service  Station  (FSS)  person-to-person  briefings  was  achieved  as  a  direct 
result  of  the  PATWAS  system.  It  was  also  noted  that  the  general  aviation  public 
strongly  favored  the  route-oriented  briefing  technique  incorporated  in  the  system. 

A  few  shortcomings  were  also  observed  in  the  New  York  City  PATWAS  system  and  were 
pointed  out  as  potential  areas  for  improvement  in  any  future  work  in  this  facet  of 
the  FSS  automation  effort.  Some  of  the  more  important  areas  of  improvement  are 
noted  below: 

1.  The  "barge-in*1  connection  was  found  to  be  inconvenient  to  the  pilot,  since  it 
had  a  tendency  to  increase  his  line-hold  time  to  obtain  complete  message  content , 
which  increases  line  costs  ot  the  system  making  it  undesirable  as  a  functional 
in- the- field  system. 

2.  The  speech  quality  of  the  recordings  need  improvement  with  respect  to  speech 
consistency  and  audio  recording  levels. 

3.  "One-call"  service  was  considered  to  be  a  desirable  feature  by  many  of  the 
subjects  that  used  the  system. 

The  New  York  City  PATWAS  test  proved  without  a  doubt  that  a  system  conf igur at  ion  of 
this  type  would  meet  with  general  aviation  public  acceptance  and  would  reduce  the 
workload  of  the  FSS  specialist  by  a  significant  amount.  It  was  further  observed 
that  research  and  development  of  the  system  should  be  conducted  in  Lhe  following 
areas : 

a.  Non i nt er rupt i ng  fast-time  updating  of  weather  information 

b.  Multiple  message  storage 

e.  Accessing  message  at  beginning 

d.  Multiple  message  availability  of  any  telephone  line 

e.  One  telephone  number  access 

f.  Automatic  message  composition 

g.  Centralized  message  composition 

h.  User  selection  of  specific  message  segmenls. 

The  conclusions  and  recommendations  found  in  this  report  provided  the  impetus  for 
the  mass  weather  d i ssemi nat i on  exploratory  engineering  model  developed  at  the 
Federal  Aviation  Administration  (FAA)  Technical  Center  and  described  in  this 
report. 

The  reader  is  referred  to  figure  2  for  clarification  of  interrelationship  of  system 
elements  in  the  following  development  discussion. 
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FIGURE  2.  MASS  WEATHER  DISSEMINATION  EXPLORATORY  ENGINEERING  MODEL 

HISTORICAL  DEVELOPMENT  OF  THE  MASS  WEATHER  DISSEMINATION  SYSTEM 


GENERAL. 

The  mass  weather  dissemination  system  exploratory  engineering  model  developed  at 
the  FAA  Technical  Center  was  modeled  after  the  magnetic  tape  cassette  system  used 
for  experiment  at  LaGuardia.  This  PATWAS  system  incorporated  some  innovative 
concepts,  but  also  had  some  severe  limitations.  The  PATWAS  tape  system's  major 
advantage  is  the  ability  to  update  segments  of  the  total  message,  rather  than  the 
entire  message,  due  to  the  fact  that  the  tape  transport  sequenced  through  a  number 
of  cassettes  via  queue  tone  controls  recorded  on  the  tape  along  with  the  audio 
data.  This  feature  allowed  for  the  segmentation  of  a  rout e-or i ented  briefing  into 
a  subset  of  message  segments,  thus  aL Lowing  for  partial  message  update  capability. 

The  major  drawbacks  to  this  tape  system  were  that  each  tape  transport  which 
constitutes  a  route-oriented  briefing,  is  attached  to  a  Telephone  Company  (Telco) 
barge-in  system.  Severe  system  limitations  were  experienced,  due  to  the 
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hardwired  nature  of  fabrication  and  the  Lack  of  artificial  intelligence  to  make 
decisions.  Two  of  the  most  prominent  problems  which  plagued  the  system  are 
described  below. 

1  •  When  the  first  pilot  accesses  a  quiescent  tape  transport  constituting  a 
briefing,  he  initiates  the  message  and  proceeds  to  sequent  *  through  the  tapes  com¬ 
prising  this  briefing;  if  now  a  second  pilot  accesses  this  briefing,  he  barges-in 
picking  up  the  briefing  at  the  point  in  time  that  the  first  pilot  has  progressed 
into  the  message.  Since  the  second  pilot  is  Listening  to  the  message  out  of 

context,  he  more  than  likely  will  have  to  sequence  through  the  briefing  which  is 
inconvenient  to  the  pilot  and  increases  his  line-hold  Lime  which  is  costly  to  the 
gove  r  nine  ill . 

'Hie  other  major  problem  enountered  in  the  system  is  the  inability  to  have 

me ssage-t o- 1 i ne  multiplexing.  What  is  meant  by  this  is  that  each  barge- in  system 
has  a  number  of  phone  lines  hard-wired  to  it  and  if  a  pilot  cal Ls  a  briefing  system 
which  is  fully  utilized,  he  will  receive  a  busy  signal  even  though  other  lines  on 
different  briefing  systems  may  be  available.  This  inability  to  switch  a  desired 
briefing  to  a  designated  line  mandates  inefficient  line  utilization  at  an  FSS 

i ns tal lation. 

With  these  thoughts  in  mind,  it  was  decided  to  try  to  incorporate  the  ability  to 
update  a  portion  of  a  briefing,  rather  than  recording  the  entire  message,  and  in 
addition,  have  synchronous  access  and  message-to-line  multiplexing  utilizing 
digital  technology  as  the  artificial  intelligence  of  the  system.  Synchronous 
access  is  now  readily  available  since  the  artificial  intelligence,  a  general 
purpose  minicomputer,  can  randomly  access  the  binary  data  which  constitutes  a 
particular  briefing  from  a  mass  storage  media,  transfer  this  binary  data  to  an 
audio  output  channel  wh  i ch  converts  this  data  from  the  digital  domain  back  into 
analog  signals,  reproducing  the  original  spoken  word  content  of  the  briefing.  In 
addition,  assuming  a  man-machine  interface  exists  between  piLot  and  system,  the 

minicomputer  can  ascertain  that  the  pilot  requires  a  northbound  route-oriented 
briefing;  and  randomly  access  this  particular  data  from  the  mass  storage  media  and 
disseminate  this  information  to  the  pilot  via  the  audio  output  board,  thus 
achieving  the  goal  of  switching  a  designated  message  to  a  designated  phone  line. 
The  man-machine  interface  mentioned  above  could  be  either  a  Touch-Tonem  mechanism 
or  a  word  recognition  device. 

Some  additional  system  options  could  now  be  included  because  of  the  artificial 
intelligence  incorporated  into  the  system.  Since  the  ability  exists  to  interrogate 
the  pilot  as  to  how  the  system  can  be  of  service  to  him,  he  now  has  the  ability, 
along  with  obtaining  a  rout  e-ori  ented  briefing,  to  request  to  file,  close  out, 
amend  a  flight  plan,  or  to  talk  to  a  specialist  to  assist  him  in  matters  not 
obtainable,  otherwise,  in  the  system.  In  order  to  incorporate  these  functions  into 
the  system,  three  devices  would  have  to  be  incLuded  in  the  system  architecture 
which  are  specified  below: 

1.  A  digitally-controlled  analog  tape  recorder  had  to  be  developed  that  could  be 
directed  to  perform  specific  functions,  depending  on  system  file  options  requested 
by  the  pilot.  Among  the  commands  required  would  be  record,  rewind,  replay,  and 
filemark.  With  this  repertoire  of  commands  and  the  interaction  of  man  and  system, 
it  is  possible  to  file  and  review  a  flight  plan  without  human  intervention. 
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2.  A  digi t a L Ly-cont rol L ed  handset  that  i he  computer  could  sense,  if  available  and 
if  so,  generate  an  alert  signal  to  a  specialist  that  a  pilot  required  human 
assistance.  In  addition,  the  handset  would  have  to  communicate  back  to  the  system 
that  the  spec  i  al  i  st -p  i  1  »U  coinmun  i  cal  i  on  was  done  or  t  lie  specialist  had  to  go  off¬ 
line  and  would  not  accept  the  call  The  computer  could  then  take  the  appropriate 
action  to  further  assist  the  pilot. 

3.  A  crosspoint  switch  mechanism  would  have  to  be  fabricated  and  incorporated  into 
the  system,  again  under  computer  control,  in  order  to  achieve  the  audio  switching 
necessary  to  get  a  specified  phone  line  to  a  specific  sysLem  option. 

With  the  inclusion  of  these  items  in  the  sysLem,  it  is  evident  that  the  pilot  has  a 
much  broader  range  of  services  available  to  him,  than  those  available  in  the 
magnetic  tape  FA TWAS  system.  The  pilot  could  now  have  the  ability  to  acquire  a 
route-oriented  briefing  and  file  a  flight  plan,  with  or  without  specialist 
assistance,  by  a  single  caLL  access  to  the  system. 

MINICOMPUTER  SELECTION. 

The  minicomputer  selected  as  the  artificial  intelligence  of  the  system  was  the 
Perkin-Elmer  Interdata  7/32.  Some  of  the  salient  features  of  this  computer,  which 
made  it  desirable  for  our  particular  applications,  are  listed  below. 

1.  The  ability  to  communicate  with  up  to  1,024  peripheral  devices  attached  to  the 
computer's  multiplexer  bus. 

2.  A  32-bit  machine  architecture  making  possible  the  ability  Lo  directly  address 
multiple  megabytes  of  memory. 

3.  An  operating  system  that  provided  many  desirable  features  built-in,  along  with 
a  real-time,  multitasking  environment. 

After  the  audio  input/output  boards  were  designed  and  fabricated  to  be  compatible 
with  the  bus  structure  and  interrupt  protocols  of  the  interdata  machine,  it  was 
necessary  to  produce  a  software  driver  for  the  boards  which  would  allow  a  new 
operating  system  to  be  generated.  This  new  "SYSGENED"  operating  system  could  then 
treat  the  alien  devices  as  though  it  were  any  standard  interdata  dr iver/peripheral 
product,  allowing  the  system  to  handLe  the  audio  input/output  boards  as  "logical 
units,"  thereby  making  them  attachable  to  tasks  present  in  the  multitasking 
environment.  This  marriage  of  the  in-house  designed  audio  boards  to  the  operating 
system  was  necessary  in  order  to  take  advantage  of  the  powerful  features  built  into 
the  operating  system  software. 

One  of  the  features  of  the  operating  system  that  was  very  desirable  was  the  support 
of  a  multitasking  environment.  This  environment  was  necessary  since  the  overall 
system  would  produce  a  number  of  interrupts,  some  of  which  were  time-critical  while 
others  were  not.  An  example  of  a  time-critical  interrupt  is  one  from  an  audio 
board.  The  board  has  two  on-board  buffers,  one  of  which  is  playing  out  as  audio; 
the  other  to  be  filled  with  the  next  sequential  binary  data.  From  this  it  can  be 
seen  that  if  the  second  buffer  is  not  filled  by  the  time  the  first  buffer  is 
exhausted,  an  interruption  in  audio  output  will  result.  An  example  of  a  nontime- 
critical  interrupt  is  a  communication  entered  by  the  specialist  to  the  system,  from 
his  display  terminal.  The  system  intercepts  these  interrupts  at  the  firmware  level 
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and  processes  them  into  system  queues  which  are  then  disseminated  to  the 
appropriate  tasks1  queue  list.  The  system  works  in  an  asychronous  nature  with 
respect  to  these  interrupts  which  would  resulL  in  a  mix  of  time-critical  and 
non t ime-c r i t i cal  queues  in  the  tasks'  queue  list.  Since  the  task  has  to  handle  its 
queue  list  in  a  sequential  fashion,  rather  than  on  a  priority  basis,  it  is  evident 
that  a  time-critical  queue  could  miss  getting  serviced  within  the  given  time 
window.  Since  the  operating  system  along  with  being  multitasking,  allows  the  tasks 
to  be  assigned  a  system  priority,  it  is  seen  that  the  problem  of  servicing  this  mix 
of  system  queues  can  be  resolved.  The  solution  is  to  segregate  t ime-c r i t i cal 
queues  to  tasks  with  a  high  sysLem  priority  and  nont ime-c r i t i cal  queues  in  tasks 
with  lower  system  priority.  In  this  manner,  t  he  critical  queues  will  be  serviced 
by  the  system  before  t  lie  non  l  ime-c  r  i  L  i  c  al  queues  get  system  attention. 

Another  feature  ol  the  operating  system  which  was  felt  would  greatly  enhance  our 
development  time  of  the  mass  weather  dissemination  exploratory  engineering  model 
was  the  file  management  software  incorporated  as  part  of  the  operating  system 
environment.  In  order  to  achieve  system  throughput  efficiency  to  the  level 
necessary  to  service  the  required  20  audio  boards  simultaneously,  a  marriage  had  to 
be  made  between  existing  file  management  software  in  the  operating  system  and  a 
pseudo-file  management  software  package  developed  in-house. 

FILE  MANAGEMENT  DESCRIPTION. 

The  first  file  management  technique  experimented  with  was  the  indexed  tile 
structure,  since  this  provided  the  most  ease  of  implementing  and  provided  the  most 
efficient  utilization  of  the  storage  media.  When  this  file  management  method  was 
employed  to  handle  the  briefing  data,  it  was  determined  that  each  audio  board 
required  20  percent  of  the  overall  system  for  file  management  and  other  system 
overhead.  This  Large  overhead  figure  was,  in  large  part,  due  to  the  double 
buffering  of  the  data,  once  at  the  system  level  and  again  at  the  task  level.  The 
manner  in  which  indexed  files  are  generated  is  another  reason  whicli  contributes  to 
the  slow  response.  A  data  request  may  require  multiple  seeks  on  the  storage  device 
because  of  the  random  nature  in  which  it  is  written  on  the  media;  thus  increasing 
the  total  response  time  by  the  additional  seeks  being  done.  Since  this  tremendous 
overhead  would  reduce  the  number  of  boards  that  could  be  serviced  simultaneously 
down  to  five  boards;  the  indexed  file  management  technique  had  to  be  aborted, 
despite  its  very  efficient  utilization  of  the  storage  media  and  ease  of 
impl ementat ion . 

The  next  file  management  technique  pursued  was  the  contiguous  file  manager.  This 
management  scheme  does  not  encounter  the  problems  inherent  in  the  indexed  file 
management.  The  information  is  not  double  buffered;  it  is  transferred  directly 
from  the  storage  media  to  the  task's  storage  buffer.  In  addition,  because  of  the 
nature  of  a  contiguous  file,  information  within  the  file  can  be  positioned 
randomly;  and  then  read  in  a  sequential  manner  from  thai  point  to  satisfy  the 
request,  thus  eliminating  additional  seek  times  to  the  overall  response  time  of  a 
read  request.  The  contiguous  file  management  overhead,  for  these  reasons,  is 
drasticaLLy  reduced.  The  total  system  overhead  per  board  was  reduced  from  20 
percent  to  5  percent,  which  brought  the  system  much  closer  to  the  desired  specifi¬ 
cation  of  being  able  to  simultaneously  service  20  audio  boards. 
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The  contiguous  tile  management  is  not  without  its  short  coinings,  however.  The 
major  drawback  to  tins  management  method  is  that  in  order  to  allocate  a  continguous 
tile  on  the  storage  media,  the  size  of  the  file  has  to  be  known  at  time  of  allo¬ 
cation,  since  a  eontinous  physical  area  of  the  specified  size  has  lo  be  found  on 
the  media.  This  phenomenon  generates  some  severe  problems.  Mosl  obvious  of  these 
problems  becomes  evident  immediately;  i.e.,  the  specialist  does  not  know  the  time 
duration  of  a  message  segment  until  he  speaks  it  into  the  system;  therefore,  a 
continguous  file  cannot  be  allocated  for  thi s  segment  beforehand. 

The  solutions  to  this  aforementioned  problem,  although  rectifying  the  condition, 
are  not  considered  viable  solutions  due  to  either  excessive  overhead  or  inefficient 
utilization  of  the  storage  media.  One  such  solution  would  be  to  attach  an  indexed 
file  first  and  speak  the  segment  allowing  the  system  to  expand  the  indexed  file,  as 
necessary,  to  accomodate  the  segment  and  upon  completion,  now  knowing  the  size  of 
the  file,  allocate  a  contiguous  file  of  sufficient  capacity  to  then  transfer  the 
indexed  file  counterpart;  the  indexed  file  could  then  be  deleted.  It  is  evident 
that  this  technique  would  incur  a  great  deal  of  system  overhead.  Another  possible 
solution  is  to  preallocate  contiguous  files  on  the  storage  media  o  l  various  Lime 
durations;  i.e.,  I  minute,  2  minutes,  etc.  It  is  obvious  that  this  would  be  both 
ve ry  cumber. some  to  the  specialist  to  have  to  fit  a  message  segment  within  a 
specified  time  slot  or  by  attaching  a  file  of  considerably  larger  capacity  than 
anticipated  for  the  segment,  cause  inefficient  utilization  of  the  storage  media. 
Additional  system  overhead  is  also  incurred  from  the  attaching  and  closing  of  these 
contiguous  files  to  a  specified  task  and  deletion  of  noncurreni  segment  files. 

In  order  to  take  advantage  of  the  efficiencies  obtained  by  using  the  contiguous 
file  manager  and  not  incur  the  deficiencies  just  described,  a  pseudo-file  manager 
was  conceived  and  developed  in-house  and  implemented  into  the  system  at  the  task 
leveL.  The  mass  storage  media  eluded  to  in  the  previous  discussion  is  a  fixed  head 
disc.  One  track  of  the  25b  tracks  on  the  fixed  head  disc  hoLds  approximately  4 
seconds  worth  of  digitally  encoded  speech.  On  this  basic  premise,  an  algorithm  was 
written  to  maintain  records  on  track  utilization.  The  name  given  to  this  track 
management  algorithm  was  r andom-conl i guous  track  management. 

The  first  order  of  business  was  to  allocate  a  contiguous  file  on  the  disc  of  a 
size  tli at  required  all  of  the  available  storage  area  on  the  media.  Now,  by 
a  1 1  a c It  i  n g  t  i  ^ e  files  l  o  a  task,  since  the  system  has  1  i  v e  fixed  head  discs, 
20  megabytes  ot  binary  data  (85  minutes  worth  of  speech)  is  available  to  this  task 
Next  ,  it  is  necessary  to  have  a  track  map  in  core  tor  each  ot  the  discs  to  indi¬ 
cate  which  tracks  are  available  for  use  and  which  tracks  are  dedicated  to  an 
already  existing  segment.  Finally,  a  segment  table  is  required  to  indicate  the 
sequence  of  tracks  to  play  out  to  generate  a  specified  segment  within  a  desired 
rout e-or i ented  briefing. 

In  essence,  the  algorithm  would  go  through  the  following  sequence.  Once  it  is 
ascertained  which  route-oriented  briefing  is  desired,  the  route  table  is  accessed 
to  see  if  the  first  segment  is  active  and  if  it  is,  fetches  its  segment  block 
address  within  the  segment  table.  Within  this  segment  block  are  a  number  of  binary 
words  which  indicate  both  the  disc  and  track  number  that  should  be  accessed  and 
disseminated.  When  this  track  is  exhausted,  the  next  word  is  fetched  and  a  similar 
operation  is  performed.  In  this  manner,  tracks  are  sequenced  through  until  t  lie 
last  track  is  accessed,  indicated  by  a  bit  within  the  word.  Embedded  within  the 


word  is  also  the  informal  ion  of  how  ranch  of  the  Last  track,  to  play  out  in  order  to 
eliminate  dead  Lime  at  the  end  of  the  segment.  The  algorithm  would  then  access  the 
route  table  to  see  if  tin*  next  segment  is  active  and  if  it  is,  go  through  a  similar 
process  just  described.  In  this  manner,  the  entire  briefing  would  be  d i sserai nated , 
playing  all  segments  within  it  that  are  presently  active. 

By  the  nature  in  which  the  algorithm  functions,  it  is  evident  that  a  segment  can  be 
of  any  duration,  within  the  bounds  of  available  storage,  because  of  the  process  of 
looking  for  an  available  track  anywhere  within  the  five  media.  If  a  segment  block 
is  filled,  the  algorithm  wi  1 L  automatically  look  for  another  available  segment 
block  within  the  segment  table  and  use  the  last  word  of  the  oLd  segment  block  to 
point  to  the  new  segment  block  which  will  contain  the  remainder  of  the  track/disc 
information  for  that  segment. 

A  final  point  that  should  be  noted  is  that  additional  overhead  is  eliminated 
because  no  file  manipulations  are  performed,  such  as  attaching  or  closing  out  a 
file  to  a  task.  Add  i  t  i  onal  [y ,  when  an  out-dated  segment  is  to  be  deleted,  no 
action  is  taken  on  Che  physical  media;  instead,  the  tracks  which  constituted  this 
segment  are  made  available  again  in  the  appropriate  track  maps,  making  deletions  a 
very  expeditious  procedure. 

FUNCTIONAL  DESCRIPTION  OF  THE  MASS  WEATHER  DISSEMINATION  EXPLORATORY 
ENGINEERING  MODEL. 


The  mass  weather  dissemination  exploratory  engineering  model  is  composed  of  the 
following  functional  components: 

1.  TeLco  line  controller 

2.  Telco  output  channel  interface 

3.  Interdata  7/32  computer 

4.  Printer 

5.  Bulk  store 

6.  Voice  digitizer 

7.  Fast  file 

8.  Flight  plan  entry  console 

9.  Specialist  answering  set 

10.  Message  entry  console 

Figure  2  shows  the  i nter reiat i onshi p  of  these  elements  as  a  system. 

The  Telco  line  controller  and  output  channel  interface  are  the  elements  that 
connect  the  system  to  the  outside  world.  The  TeLco  line  controller  alerts  the 
computer  of  such  conditions  as  ring  detect,  customer  disconnect,  and  also  provides 
pickup  condition  for  the  phone  line.  The  Telco  output  channel  interface  is  the 
device  that  converts  the  digitaL  speech  data  in  the  bulk  storage  back  into  analog 
signaLs  compatible  with  the  phone  line  environment. 

The  Interdata  7/32  computer  is  the  decisionmaking  element  of  the  system  and 
controls  the  flow  of  the  caller  through  the  system,  depending  on  options  specified 
by  the  pilot  calling  in.  The  computer  is  capable  of  switching  the  caller  to  any  of 
the  system  options  specified,  via  use  of  a  crosspoint  switch  array  and  crosspoint 
controller.  The  computer  also  decides  what  system  question,  statement,  or  weather 
message  will  be  disseminated  to  the  pilot  over  the  output  channel  interface. 


The  message  entry  console,  voice  digitizer,  and  buLk  store  constitute  the  eLeraents 
necessary  to  enter  weather  messages  into  the  system  for  d i ssemi nat ion  over  the 
phone  Line.  The  specialist  issues  commands  from  his  position  which  are  interpreted 
by  the  computer  and  executed  to  fulfil.  I  the  request.  An  example  of  such  a 
transaction  would  be  as  follows: 

The  specialist  would  "talk11  a  valid  segment  name  which  constitutes  one  of  the 
components  of  a  route-oriented  briefing.  The  computer  would  accept  the  binary 
information  from  the  voice  digitizer,  store  this  information  on  an  available  area 
of  the  bulk  storage  devices;  and  finally,  pLace  pointers  in  memory  for  retrieval 
by  the  playback  algorithm  so  that  this  information  can  be  disseminated  at  the 
appropriate  lime  in  the  specified  route-oriented  briefing. 

The  Nisi- tile  recorder,  flight  plan  entry  console,  and  printer  comprise  the 
elements  necessary  tor  handling  flight  plans  in  the  system.  When  a  pilot  says 
"file,"  tiie  computer  switches  him,  via  the  crosspoint  switch/controller,  to  an 
analog  tape  recorder  which  is  under  digital  control  by  the  computer.  By  use  of 
this  conf igur at i on,  the  system  can  record  a  fLight  plan,  allow  the  pilot  to  review 
or  amend  a  flight  plan;  and  finally,  to  close  out  a  flight  plan.  The  flight  plan 
entry  position  allows  the  specialist  to  enter  the  flight  plan  information  from  the 
analog  tape  into  the  system,  by  means  of  a  keyboard/display  terminal.  The  infor¬ 
mation  is  processed  and  properly  formatted  for  transmission  on  the  service  MB" 
circuit.  A  hard  copy  of  the  flight  plan  can  also  be  obtained  from  the  printer  for 
local  retention  of  the  flight  plan  at  the  originating  FSS. 

The  specialists'  answering  sets  are  an  in-house  automatic  telephone  call 
distributor  system  handled  in  the  software  domain.  When  a  pilot  requests  a 
"specialist,"  the  computer  looks  for  an  available  position  and  issues  a  ring 
command  to  that  position.  If  the  specialist  picks  up  the  handset,  the  computer 
connects  the  pilot's  telephone  line  to  the  appropriate  handset,  via  the  crosspoint 
switch /controller.  At  completion  of  the  communication  between  pilot  and 
specialist,  the  handset  sends  a  signal  to  the  computer  which  prompts  the  playing  of 
a  "system"  question  asking  the  pilot  if  the  system  can  be  of  any  further 
assistance.  If  the  specialist,  at  the  time  of  a  "ring"  condition  on  his  handset 
has  a  higher  priority  task  to  perform,  he  can  place  his  handset  "off-line,"  which 
alerts  the  computer  that  this  position  is  now  not  available  and  to  scan  the 
system  for  another  available  handset.  If  a  handset  cannot  be  found,  the  pilot 
is  placed  on  a  "wait"  list  until  a  handset  becomes  available. 

DESCRIPTION  OF  PROGRAM  FLOW  CHART  FOR  THE  MASS  WEATHER  DISSEMINATION  EXPLORATORY 
ENGINEERING  MODEL. 

To  describe  the  program  Logic  flow  of  the  system,  a  narrative  description  of  a 
typicaL  transaction  between  pilot  and  system,  with  multiple  options  selected,  will 
be  given.  For  the  sake  of  clarity,  perfect  recognition  wi  1  L  be  assumed  and  the 
short  form  of  the  questions  and  statements  will  be  requested.  The  interested 
reader  can  follow  tin1  fLow  sequence  for  these  circumstances  in  the  flow  chart 
(figure  3)  and  listings  of  the  system  questions  and  statements,  included  here  for 
the  reader's  convenience. 
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BRIEFING 


FIGURE  3.  PROGRAM  FLOW  CHART  FOR  THE  MASS  WEATHER  DISSEMINATION 
EXPLORATORY  ENGINEERING  MODEL  (2  of  9) 
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SPECIALIST 


FIGURE  3. 


PROGRAM  FLOW  CHART  FOR  THE  MASS  WEATHER  DISSEMINATION 
EXPLORATORY  ENGINEERING  MODEL  (3  of  9) 


DATA  RECORDED  ANO  PROCESSED 
BY  THE  FAA  TECHNICAL  CENTER 


FIGURE  J. 


PROGRAM  FLOW  CHART  FOR  THE  MASS  WEATHER  DISSEMINATION 
EXPLORATORY  ENGINEERING  MODEL  (4  of  9) 


FIGURE  3.  PROGRAM  FLOW  CHART  FOR  THE  MASS  WEATHER  DISSEMINATION 
EXPLORATORY  ENGINEERING  MODEL  (5  of  9) 
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data  recorded  and  processed 
gyTwc  caA  technical  center 


ERROR  CORRECTION 


OPTION  CORRECTION 


ROUTE  CORRECTION 


DATA  RECORDED  AND  PROCESSED 
BY  THE  FAA  TECHNICAL  CENTER 


FIGURE  3. 


PkOGRAM  FLOW  CHART  FOR  THE  MASS  WEATHER  DISSEMINATION 
EXPLORATORY  ENGINEERING  MODEL  (8  of  9) 


ERROR  CORRECTION  FOR  YES/NO 


FIGURE  4.  PROGRAM  FLOW  CHART  FOR  THE  MASS  WEATHER  DISSEMINATION 
EXPLORATORY  ENGINEERING  MODEL  (9  of  9) 
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Upon  reception  of  a  "ring"  signal  on  one  of  the  Telco  line  controllers,  the 
computer  is  alerted  to  this  fact  and,  in  response,  the  computer  directs  the  appro¬ 
priate  Telco  output  channel  interface  board  to  execute  a  pickup  function  and  then 
disseminate  the  introduction  to  the  pilot  which  poses  the  first  question  pertaining 
to  whether  the  caller  needs  detailed  operating  i ns t rue t ions .  If  the  caller's 
response  is  "no,"  the  computer  conditions  this  board's  output  to  Lhe  short  form  of 
system  questions  and  statements  for  the  duration  of  the  transaction. 

The  next  question  asked  of  the  pilot  is  "OPTSEL"  which  requests  which  system  option 
the  piLot  would  like  to  use.  Let  us  assume  the  first  order  of  business  is  a  route- 
oriented  briefing.  Upon  reception  of  the  word  "briefing"  from  the  pilot,  the 
system  responds  with  another  question  (RTESEL)  which  requests  which  of  the  five 
route-oriented  briefings  lie  wishes  to  hear.  For  discussion  purposes,  let  us  assume 
the  caller  says  the  word  "north."  The  system  would  then  disseminate  Lhe  current 
northbound  briefing  to  the  pilot. 

At  the  conclusion  of  the  briefing,  the  system  question  "EFILE"  is  played  asking  the 
pilot  if  he  requires  any  further  information  or  assistance.  Let  us  assume  the 
pilot  needs  some  specific  information  not  contained  in  Lhe  briefing  and  desires  to 
talk  to  a  specialist.  With  this  being  the  case,  the  pilot  would  say  "yes"  to  the 
"EFILE"  question,  at  which  time  the  "OPTSEL"  question  is  played  to  the  pilot.  At 
the  conclusion  of  this  question,  the  pilot  would  speak  the  word  "specialist."  The 
computer  would  then  play  the  system  statement  "special"  which  informs  the  pilot 
Chat  he  should  standby  for  a  specialist. 

At  the  conclusion  of  the  conversation  between  the  pilot  and  specialist,  the  system 
again  asks  the  question  "EFILE , "  asking  the  pilot  if  it  can  be  of  any  further 
assistance.  Let  us  suppose  the  pilot  has  sufficient  information  to  fly  and  now 
wishes  to  file  a  flight  plan.  The  pilot  again  would  say  "yes"  to  the  "EFILE" 
question  and  the  word  "file"  to  the  "OPTSEL"  question.  The  system  would  then  play 
out  the  statement  "FASTF1L"  which  tells  the  pilot  to  standby  to  speak  his  flight 
plan  immediately  after  the  queue  tone. 

At  the  end  of  his  flight  plan,  the  pilot  remains  silent  for  5  seconds  which  alerts 
the  computer  that  Lhe  flight  plan  has  been  completed.  The  system  question  "ENDFF" 
is  then  played  to  the  pilot  which  asks  him  if  he  would  like  to  review  his  flight 
plan.  Let  us  assume  a  "yes"  answer  to  this  question;  this  would  cause  the  computer 
to  issue  a  rewind/play  command  to  the  fast  file  recorder  which  allows  the  pilot  to 
hear  the  flight  plan  he  has  just  spoken  into  the  system. 

When  the  flight  plan  review  is  completed ,  the  system  comes  back  to  the  pilot  with 
the  question  "PRENDFF"  which  asks  the  pilot  if  he  would  like  to  make  any  amendments 
to  his  flight  plan.  Assume  chat  the  pilot  detected  an  error  in  his  flight  plan  and 
wishes  to  correct  the  erroneous  information.  This  being  the  case,  the  pilot  would 
say  "yes"  to  the  "PRENDFF"  question,  at  which  time  the  system  issues  a  statement 
telling  the  pilot  to  standby  to  speak  his  flight  plan  amendment  immediately  after 
the  queue  tone. 

At  the  conclusion  of  this  iteration,  the  system  asks  Lhe  question  "ECHANGE"  which 
wants  to  know  if  the  pilot  would  like  to  teview  his  flight  plan  amendments.  For 
the  sake  of  discussion,  let  us  assume  the  caller  would  like  to  confirm  thaL  the 
system  obtained  his  changes  properly.  The  caller  would  then  respond  with  a  "yes" 
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to  the  "ECHANGE"  question,  which  prompts  the  computer  to  send  a  rewind/play  command 
to  the  fast  file  recorder,  allowing  the  pilot  to  review  his  flight  plan  amendments. 
When  the  playback  is  finished,  the  computer  again  d  i  ssetn  i  nates  the  "PRENDFF" 
question  to  the  pilot  asking  if  he  wants  to  make  any  changes  to  his  now  modified 
flight  plan. 

Let  us  assume  the  pilot  is  now  satisfied  with  his  flight  plan  and  says  "no"  to  the 
"PRENDFF"  question.  The  system  would  then  ask  the  question  "EF1LE"  requesting  the 
pilot  if  the  system  can  be  of  any  further  assistance.  Since  the  pilot  has  accom¬ 
plished  his  goal,  he  wouLd  say  "no"  to  the  "EFILE"  question  which  would  motivate 
the  computer  to  play  the  "hangup11  statement  wishing  the  pilot  a  good  day  and 
issuing  a  hangup  command  to  the  Telco  line  controller. 

Other  permutations  that  a  pilot  would  generate  while  using  the  system  would  follow 
a  similar  logical  flow  through  the  accompanying  chart.  Other  minor  flow  sequence 
variations  would  be  generated  internally  by  the  system;  in  the  case  of  a  misinter¬ 
pretation  of  an  utterance  or  a  nonconfirmation  of  a  yes/no  question,  verification 
of  a  system  function  requested. 

The  following  is  a  tabulation  of  utterances  to  be  issued  by  the  PABS  while  engaged 
in  dialog  with  the  pilot.  Two  sets  of  utterances,  one  more  detailed  than  the 
other,  are  provided. 

LNTRODUC  Hello,  this  is  the  Pilots*  Automated  Briefing  System.  Detailed 

operating  instructions  are  available  for  the  new  or  occasional 
user.  Do  you  wish  detailed  operating  instructions?  Please  say 
,,yes*1  or  "no"  immediately  after  the  cue  tone. 

If  the  answer  to  LNTRODUC  is  "no"  the  foLLowing  set  of  utterances  wi 1 L  be  used. 

Say  "  b  r  i  e  f  i  n  g  ,  "  "file,"  "amend  "specialist,"  or  "close." 

Say  "north,"  "south,"  "east,"  west,”  or  "local." 

Standby  for  a  specialist. 

Standby  to  speak  your  flight  plan  immediately  after  the  cue 
tone . 

Do  you  wi sh  your  flight  plan  played  back? 

Do  ;ou  wish  to  amend  your  flight  plan? 


Standby  to  speak  your  flight  plan  amendment  immediately  after 
the  cue  tone. 

Do  you  wish  to  play  bick  your  flight  plan  amendment? 

Do  you  require  additional  assistance? 

Thank  you.  Have  a  good  day. 

The  computer  did  not  understand  you.  Say  again  "briefing," 
"file,"  "amend,"  "specialist,"  or  "close." 


QOPTSEL 
QRTESEL 
QSPECIAL 
QFASTF1 L 

QENDF1L 

QPRENDFF 

(^CHANGE 

QECHANGE 

QEF1LE 

QHANG-UP 

QOWHAT 


QRWHAT 

QCLOSE 

QYNWHAT 
It  the  answer 

be  used  . 

GENERAL 


OPTSEL 


RTESEL 

SPECIAL 
FAST  FIL 


The  computer  did  not  understand  you.  Say  again  "north," 
"south,"  east,"  "west,"  or  "local." 

Standby  to  close  out  your  flight  plan  immediately  after  the  cue 
tone . 

The  computer  did  not  understand  you.  Say  again  yes  or  no. 
o  INTKODUC  is  "yes",  the  following  set  of  computer  utterances  will 


During  the  briefing  you  will  be  asked  to  speak  certain  words  to 
the  computer.  We  ask  that  you  speak  clearly,  only  one  word  at  a 
time,  and  only  immediately  after  the  cue  tone. 

If  the  computer  asks  you  to  "please  repeat"  say  your  last  word 
again  immediately  after  the  cue  tone. 

If  the  computer  questions  your  last  word,  for  example  "was  that 
north:  please  say  "yes"  or  "no"  immediately  after  the  cue 
cone . 

If  the  computer  does  not  respond  in  approximately  3  seconds, 

please  say  your  last  word  again  louder. 

Do  you  wish  a  replay  of  the  information  just  presented?  Say 

"yes"  or  "no"  immediately  after  the  cue  tone. 

You  may  select  one  of  five  system  options.  You  may  select  any 

of  four  route-oriented  briefings  or  a  local  area  briefing.  You 

may  speak  your  flight  plan  into  fast  file,  amend  a  previously 
entered  flight  plan,  or  close  out  a  flight  plan.  You  may  speak 
to  a  Flight  Service  Specialist.  You  may  terminate  this  call  at 
any  time  by  merely  hanging  up.  Immediately  after  the  cue  tone, 
please  say  "briefing,"  "file,"  "specialist,"  "amend,"  or 
"close." 

To  select  a  generally  northbound  route-oriented  briefing  say  i 
word  "north."  Similarly,  say  "east,"  "south,"  or  "west"  t^r 
other  route-oriented  briefings,  or  the  wora  "local"  for  a  local 
area  briefing.  Immediately  after  the  cue  tone  say  "north," 
"east,"  "south,"  "west,"  or  "local." 

Standby  for  a  specialist. 

You  will  be  connected  to  the  fast-file  system.  Standby! 
Immediately  after  the  cue  tone  speak  your  flight  plan. 

The  computer  will  interpret  5  seconds  of  silence  as  completion 
of  your  flight  plan.  When  you  have  finished,  remain  silent 
until  the  computer  comes  back  to  you. 

Do  you  wish  to  play  back  your  flight  plan?  Please  say  "yes"  or 
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Do  you  wish  to  make  amendments  to  your  flight  plan?  Please  say 
"yes"  or  "no." 

You  will  be  connected  to  the  "fast-file'*  sysLem.  Standby! 
Immediately  after  the  cue  tone  speak  your  flight  plan  amend¬ 
ments.  Say  the  word  "amend,"  identify  yourself,  your  aircraft, 
and  previously  entered  estimated  time  or  departure.  When  you 
have  finished,  standby,  the  computer  will  come  back  t  you. 


Do  you  wi sh  to  play  back  your  flight  plan  amendments?  Please  say 
"yes"  or  "no.*1 


Do  you  require  any  further  information  or  assistance?  Please 
say  "yes"  or  "no." 


Thank  you.  Have  a  good  day. 

The  computer  did  not  understand  you.  Please  speak  clearly 
immediately  after  the  cue  tone  one  of  the  following  words: 
"briefing,"  "file,"  "amend,"  "specialist,"  or  "close." 


The  computer  did  not  understand  you.  Please  speak  clearly 
immediately  after  the  cue  tone  one  of  the  following  words: 
"north,"  "east,"  "south,"  "west,"  or  "local." 


The  computer  did  not  understand  you.  Please  standby  for  a 
spec i al i st . 

You  will  be  connected  to  the  "fast-file"  system.  Standby! 
Immediately  after  the  cue  tone,  say  the  word  "close"  followed 
by  your  name,  aircraft,  I.D.  ,  and  time  of  day. 


The  computer  did  not  understand  you.  Please  speak  clearly 
after  the  cue  tone  either  the  word  "yes"  or  "no." 


'Hie  fast  file  recorder  has  jammed.  Standby  for  a  flight 
service  specialist  who  will  accept  your  fight  plan.  Please 
tell  the  specialist  the  recorder  is  jammed. 


DESCRIPTION  OF  THE  MANUAL  VOICE  INPUT  SUBSYSTEM  FLOW  DIAGRAMS  OF  THE  MASS  WEATHER 
DISSEMINATION  SYSTEM. 

In  order  to  describe  the  logic  flow  of  the  manual  voice  input  subsystem,  a  few 
specialist  command/machine  response  iterations  will  be  described  and  can  be 
followed  by  referring  to  figure  4.  The  logic  flow  involving  the  r andom-cont iguous 
track  management  will  be  left  to  the  interested  reader  to  follow,  since  a  narrative 
description  of  the  algorithm  is  considered  too  tedious  to  include  here  and  outside 
the  scope  of  this  report. 

Let  us  assume  the  specialist  has  a  new  terminal  forecast  ("FT")  for  the  northbound 
route  to  enter  into  the  system  for  dissemination  to  the  aviation  public.  The 
first  order  of  business  would  be  to  "map"  the  northbound  route  to  see  if  the  "FT" 
segment  is  currently  active.  The  computer  would  interpret  the  command  and  operand 
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FIGURE  4.  MANUAL  VOICE  INPUT  SUBSYSTEM  FLOW  DIAGRAM  (1  of  11) 
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FIGURE  4.  MANUAL  VOICE  INPUT  SUBSYSTEM  FLOW  DIAGRAM  (2  of  11) 
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FIGURE  4.  MANUAL  VOICE  INPUT  SUBSYSTEM  FLOW  DIAGRAM  (4  of  11) 


1 


DETERMINE 
OPERAND’S 
POSITION  IN 
ROUTE  TABLE 


S'  THERE  A  \ 
CURRENT  OPERAND 


ERROR 

MESSAGE 


'OPERAND  ACTIVE 


FETCH 

SEGMENT 

ADDRESS 


BUMP 

SUB- ELEMENT 
POINTER 


SEGMENT  \ 
DONE  CONDITION 


DATA  RECORDED  AND  PROCESSED 
BY  THE  FAA  TECHNICAL  CENTER 


THIS  LAST 
SUB- ELEMENT 
X  T  / 


USE  THIS  SUB¬ 
ELEMENT  FOR 
ADDRESS  OF  NEXT 
SEGMENT 


FIGURfc  4.  MANUAL  VOICE  LNPlJT  SUBSYSTEM  FLOW  DLAGRAM  (5  of  il) 


K I  ill  IKK  . 


MANii.M.  VOICK  INPUT  SllHSYSl'KM  Kl.OW  UIATKAM  U>  ,>l  I  I  ) 


81-33-4 (ft) 


KICURK  4. 


MiXNUAI.  VO  I  OK  INPUT  SUBSYSTEM  KI.OW  I)  lAlJRAM  17  ot  II) 


FIGURE  4.  MANUAL  VOICE  INPUT  SUBSYSTEM  FLOW  DIAGRAM  (S  of  II) 


JO 


DATA  RECORDED  AND  PROCESSED 
BY  THE  FAA  TECHNICAL  CENTEH 


POSITION  IN  ROUTE  TABLE 
TO  ROUTE  SPECIFIED  IN 
OPERAND 


DATA  RECORDED  AND  PROCESSED 
BY  THE  FAA  TECHNICAL  CENTER 


81- VT-4(0 


FIGURE  4.  MANUAL  VOICE  INPUT  SUBSYSTEM  FLOW  DIAGRAM  (10  of  11) 


12 


DATA  RECORDED  AND  PROCESSED 
8V  THE  EAA  TECHNICAL  CENTER 


81-33-400 


MANUAL  VOICK  INPUT  SUBSYSTEM  PLOW  DIAGRAM  (11  ot 

3  > 


FIGURE  4. 


typed  on  the  keyboard,  by  the  specialist,  and  if  both  parameters  were  valid  it 
would  present  the  northbound  route  map  on  the  specialises  CRT  display  which  would 
show  the  currently  active  segments  in  this  specific  route  briefing. 

The  specialist  at  this  time  may  want  to  "listen'1  to  Lhis  "FT"  segment  to  confirm 
that  the  information  being  disseminated  is  not  current.  If  the  command  and  operand 
are  valid,  the  algorithm  checks  to  see  if  the  segment  is  active  and,  if  so,  fetches 
the  segment  address.  The  segment  is  disseminated  to  the  specialist's  position,  a 
track  at  a  time,  until  Lhe  "segment  done"  condition  is  delected,  at  which  Lime  the 
specialist  can  enter  his  next  command  for  the  system  to  execute. 

The  specialist,  at  this  time,  would  now  "talk"  the  current  "FT"  segment  into  the 
system.  The  algorithm  would  seek  out  available  tracks,  as  needed,  to  enter  the  new 
message  segment  into  the  system.  The  specialist  enters  a  carriage  return  at  his 
keyboard  when  he  is  done  inputting,  which  thus  allows  a  segment  to  be  of  any 
duration,  with  the  only  limitation  being  the  storage  capacity  of  the  system. 

Upon  completion  of  this  "talk"  operation,  the  segment  just  entered  can  be  reviewed 
for  content  accuracy  and  speech  clarity,  by  entering  a  "review"  command  and  the 
appropriate  segment  name.  If  the  specialist  is  satisfied  with  the  new  message 
segment,  he  would  "update"  the  "FT"  segment  into  the  system.  The  next  caller  that 
requests  the  northbound  briefing  would  now  receive  Lhis  new  "FT"  segment  as  part  of 
Lhe  message  presentation. 

For  the  sake  of  discussion,  let  us  assume  that  the  specialist  discovers  that  he 
entered  the  wrong  information  for  the  MFT"  segment.  Assuming  10  minutes  have  not 
elapsed  since  the  "update"  operation,  the  specialist  can  reverse  the  procedure  via 
use  of  an  "abort"  operation.  By  entering  an  "abort"  command  accompanied  with  the 
appropriate  segment  name,  the  current  "FT"  segment  is  deleted  from  the  system  and 
the  old  "FT"  segment  again  becomes  the  current  "FT"  segment  for  the  northbound 
briefing.  If  an  "abort"  command  is  not  received  in  10  minutes  for  an  "update" 
command,  the  old  segment  is  deleted  from  the  system  at  the  end  of  the  time 
interval . 

Other  operations  performed  by  the  specialist  from  this  position  would  follow 
similar  flow  paths  through  the  logic  diagrams.  This  facet  of  the  software  package 
was  designed  with  a  "single-thread"  mode  of  operation  to  try  and  reduce  to  a 
minimum  the  possibility  of  erroneous  data  being  entered  into  the  system. 

The  interrelationship  of  the  tasks  and  devices  can  be  ascertained  by  referring  to 
figure  5. 

FUNCTIONAL  DESCRIPTION  OF  SYSTEM  TASKS  AND  DEVICES . 

The  three  tasks  described  in  the  following  paragraphs  constitute  the  position 
at  which  the  five  route-oriented  briefings,  which  are  composed  of  a  number  of 
SUBELEMENTS  called  segments,  can  be  monitored  and  new  message  segments  may  be 
generated  to  keep  the  briefings  current  with  the  latest  weather  data  available. 
Many  safeguards  have  been  incorporated  into  the  software  to  minimize  the  entry  of 
improper  information  oi  the  deletion  of  current  information  prematurely.  Among 
these  safeguards  are  the  restriction  of  only  speaking  a  valid  "segment  name"  and 
the  further  restraint  of  single-threading  the  operations  involved  in  making  the 
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FIGURE  5.  FUNCTIONAL  BLOCK  DIAGRAM  OF  SYSTEM  SOFTWARE 


segment  available  to  the  pilot.  An  example  of  this  is  the  fact  that  the  specialist 
either  has  to  "kill"  or  update  a  "talked"  segment  before  the  system  will  accept  a 
new  segment.  In  this  manner,  it  is  hoped  to  keep  the  specialist  cognizant  at  all 
times  of  the  functions  he  is  performing.  Other  safeguards  will  be  described  in  the 
following  discussion. 
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MESSAGE  COMPOSITION  TASK.  The  message  composition  task  incorporates  the  software 
necessary  for  the  specialist  to  monitor,  delete,  and  update  any  of  the  message 
segments  which  constitute  the  content  of  the  five  route-oriented  briefings  avail¬ 
able  to  the  pilot  in  the  system.  Since  this  task  has  no  time-critical  queues 
associated  with  it,  it  has  a  lower  system  priority  than  those  tasks  that  have  such 
time-critical  queues  associated  with  them.  This  tasks’s  functions  are  performed 
totally  asychronous  with  respect  to  system  services  being  delivered  to  pilots 
utilizing  the  system. 

The  specialist  can  listen  to  any  segment  currently  active  in  the  system  to  verify 
validity  of  message  content  and  speech  quality.  He  also  has  the  ability  to  play  a 
whole  message  in  context  to  check  for  completeness  of  information  content  and 
continuity  of  material  presented.  Finally,  the  specialist  has  the  option  to  review 
a  message  segment  just  spoken,  to  assure  proper  digitalization  ol  analog  signal, 
confirm  information  content  and  speech  quality  before  making  this  segment  available 
to  the  public  via  the  system.  All  the  above  functions  are  conveyed  via  a  super¬ 
visory  call  (SVC)  6  intertask  communication  system  function  to  the  listen  task. 

Another  function  available  to  the  specialist  is  the  ability  to  "talk”  a  new  segment 
into  the  system.  When  the  specialist  receives  updated  information  to  be  entered, 
he  simply  types  the  command  word  "talk"  and  a  valid  "segment  name"  operand.  This 
causes  an  SVC  6  intertask  communication  to  take  place  between  the  message 
composition  task  and  the  talk  task,  whose  functions  will  be  described  later. 

A  delete  function  also  exists  in  the  software  to  allow  the  specialist  to  remove 
segments  in  the  system  which  are  no  longer  current  but  have  no  update  to  replace 
them.  This  deletion  is  time  delayed  so  that  any  users  which  are  currently  acces¬ 
sing  the  now  deleted  segment  will  be  able  to  finish  listening  to  the  content  of 
this  segment;  however,  any  new  users  to  the  system  will  no  longer  be  able  to 
access  this  segment  when  listening  to  the  route  in  which  it  was  formally  active. 

The  update  command  allows  the  specialist  to  make  a  newly  spoken  segment  available 
to  the  pilot  after  the  specialist  has  reviewed  the  segment  for  correct  information 
content  and  speech  clarity. 

The  abort  command  aLLows  for  the  reversal  of  either  an  update  or  deLete  command. 
In  both  cases,  the  abort  capability  is  valid  for  a  period  of  10  minutes  from  the 
issuance  of  either  the  update  or  delete  command.  If  the  abort  is  being  executed  on 
behalf  of  a  delete  command,  the  "segment  name"  is  checked  to  see  if  an  old  segment 
exists  and  if  10  minutes  have  not  elasped,  allows  the  abortion  to  execute  making 
the  old  deleted  segment  again  the  current  active  segment.  In  the  case  of  an  update 
command,  the  abortion  replaces  the  updated  message  segment  with  the  old  saved 
segment,  if  it  exists,  and  deletes  the  update.  This  function's  primary  use  is  the 
ability  to  recover  from  the  entry  of  an  improper  update  or  deLete  command  into  the 
system . 

Two  additional  commands  that  should  be  noted  are  the  "current"  and  "kill"  commands. 
Both  of  these  functions  are  applicable  to  a  spoken  segment  that  has  not  been 
updated  into  the  system  for  a  pilot's  listening  enjoyment.  The  "current"  command 
allows  the  specialist  to  obtain  the  name  of  a  segment,  if  one  exists,  that  has  been 
spoken  into  the  system,  but  not  updated.  The  "kill"  command  allows  the  specialist 
to  delete  a  "talked"  segment  that  he  deems  invalid  i^r  entry  into  the  system  as 
part  of  the  briefing. 
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LISTEN  TASK.  The  Listen  task  is  the  means  by  which  the  system  conveys  audio 
information  to  the  specialist  upon  his  request.  The  reason  this  task  is  not  part 
of  the  composition  task  software  is  due  to  the  fact  that  the  interrupts  being 
generated  to  produce  audio  for  the  specialist  are  time-critical  in  nature.  This 
fact  mandates  that  the  priority  of  the  task  receiving  these  time-critical  queues  be 
of  equivalent  priority  to  other  tasks  in  the  system  which  have  to  respond  in  a 
timely  manner  to  queues  from  the  operating  system  environment  in  which  they  reside. 

The  listen  task  responds  to  an  SVC  b  intertask  communication  from  the  message 
composition  task  which  conveys,  in  coded  form,  the  name  of  the  segment  the 
specialist  wishes  to  review.  The  task  software  then  obtains  the  appropriate  track 
information  from  the  segment  block  and  disseminates  these  tracks  in  a  sequential 
manner  to  the  audio  board  servicing  the  specialist.  Upon  completion  of  the  Last 
track  in  the  segment,  the  listen  task  sends  a  communication  back  to  the  message 
composition  task,  taking  this  task  out  of  its  dormant  wait  state,  now  able  to 
accept  further  commands  from  the  specialist.  After  completing  this  operation,  the 
listen  task  executes  an  SVC  9,  putting  itself  in  a  wait  state  with  traps  enabled 
for  another  communication  from  the  message  composition  task  when  the  specialist 
requires  further  segments  to  be  audited. 

TALK  TASK.  The  taLk  task  is  the  mechanism  which  increases  the  specialist's 
priority  in  the  system  when  he  is  speaking  new  information  into  the  system  for  dis¬ 
semination  Co  the  pilot.  This  task  is  removed  from  a  wait-state  condition  with  the 
reception  of  an  SVC  6  commun icat ion  from  the  message  composition  task.  This 
message  conveys  coded  information  on  what  name  the  segment  will  be  associated  with 
in  the  system  if  it  is  made  an  active  segment. 

This  task  finds  an  available  track  on  the  storage  media,  and  as  buffers  of  binary 
coded  audio  information  are  generated  by  the  audio  input  board,  they  are  stored  on 
the  track.  When  this  track  is  filled,  another  free  track  is  sought  and  the  process 
is  repeated.  This  track  information  is  formed  into  a  binary  word  and  stored  in  an 
available  segment  block  for  future  access  by  the  system  for  dissemination  purposes. 
This  process  continues  until  either  the  specialist  indicates  he  is  done  via  the 
keyboard  at  his  position  or  all  available  storage  is  allocated,  at  which  time  a 
message  would  be  sent  to  the  specialist  telling  him  that  some  segments  have  to  be 
deleted  from  the  system  before  a  new  segment  can  be  generated. 

As  the  task  finds  available  tracks  in  the  track  maps  for  the  five  storage  media, 
it  sets  the  appropriate  bit  in  the  track  map  as  it  utilizes  them  for  the  segment 
being  newly  generated.  These  tracks  remain  dedicated  to  this  segment  until  it  is 
deleted  from  the  system.  This  task,  upon  reception  of  the  completion  signal  from 
the  specialist,  relinquishes  control  back  to  the  message  composition  task;  at  the 
same  time,  the  task  puts  itseLf  in  a  wait-state  with  traps  enabled  to  await  the 
next  request  by  the  specialist  to  speak  a  new  segment  of  current  weather  data. 

It  is  evident  from  the  above  discussion  that  the  three  tasks  Lhat  comprise  the 
message  entry  position  ol  the  system  gives  the  specialist  all  the  tools  necessary 
to  review,  generate,  and  replace  any  segment  within  the  system  that  makeup  the 
route-oriented  briefings.  Also  incorporated  into  the  software  are  many  safeguards 
to  protect  the  integrity  of  the  segments  making  up  the  system  route-oriented 
briefings.  Additional  protection  is  obtained  by  the  single-threading  nature  of 
operations  that  the  specialist  has  to  go  through  to  enter  new  weather  information 
into  the  system  for  dissemination  to  the  pilot. 


VOICE  BOARD  TASK. 


The  voice  board  task  is  the  interfacing  mechanism  between  pilot  and  system.  Since 
time-critical  queues  are  being  generated  by  the  voice  boards,  this  task  has  to  have 
a  higher  system  priority  to  provide  timely  servicing  of  the  system  queues  to  the 
task  in  order  to  obtain  uninterrupted  voice  output  from  the  board.  The  software 
incorporated  in  this  task  provides  all  the  logic  necessary  to  pr -sent  system  state¬ 
ments,  questions,  and  rout e-or i ent ed  briefings  to  the  pilot,  the  flow  depending  on 
options  he  lias  requested  of  the  system. 

When  the  pilot  accesses  the  system,  his  call  is  intercepted  by  the  Telco  equipment 
which  routes  the  caller  to  an  available  voice  board  in  the  system.  The  Telco 
equipment,  via  an  array  of  control  lines,  activates  a  ring  detect  signal  on  the 
voice  board  which  causes  the  board  to  generate  a  hardware  interrupt  that  the  system 
intercepts  and  converts  into  a  system  queue  that  is  sent  to  the  task  associated 
with  this  voice  board.  Upon  reception  of  this  system  queue,  the  task  software 
accesses  the  segment  block  associated  with  the  system  preamble  and  disseminates 
this  introduction  to  the  pilot.  Upon  completion  of  this  statement,  the  task  sends 
an  SVC  6  intertask  communication  to  the  monitor  conLrol  task;  the  content  of  this 
communication  contains  both  the  task/board  identification  and  coded  information  on 
which  route-oriented  briefing  or  system  message  was  just  disseminated  to  the  pilot. 
This  cask  also  incorporates  the  logic  to  decide  if  it  is  disseminating  a  system 
question  or  a  briefing.  If  it  is  a  briefing  that  is  being  disseminated,  the  task 
automatically  plays  the  entire  briefing  before  notifying  the  monitor  task  of 
completion  of  this  transaction.  The  monitor  task  is  the  control  entity  on  what  the 
voice  board  will  next  disseminate  to  the  pilot. 

CKOSSPQINT  CONTROL  TASK.  The  crosspoint  control  task  is  an  executive  task  that  was 
developed  to  communicate  with  a  controller  designed  and  built  in-house  to  operate  a 
crosspoint  switch  array.  This  array  was  needed  to  do  the  audio  switching  of  Telco 
phone  lines  to  system  utilities;  i.e,,  specialist  handsets  and  fast-file  recorders. 
This  task  receives  information  on  what  commands  to  send  to  the  crosspoint 
controller  from  the  monitor  control  task  via  SVC  6  intertask  commun i cat i on . 

An  executive  task  is  one  that  can  execute  input/output  (1/0)  type  instructions 
which  allowed  it  to  communicate  with  the  crosspoint  controller  directly,  rather 
than  using  the  system  as  an  intermediary,  as  is  the  case  with  user  tasks.  The 
advantage  of  this  approach  was  that  a  driver  did  not  have  to  be  developed  for  the 
crosspoint  controller,  thus  making  the  implementation  of  this  function  into  the 
system  a  much  more  expeditious  procedure.  The  main  disadvantage  in  using  an 
executive  task  is  that  a  piece  of  hardware,  called  a  memory  access  and  protect 
controller  (MAC)  in  the  Interdata  7/32,  is  off  when  an  executive  task  is  active. 
This  device  provides  automatic  memory  relocation  which  allows  a  user's  task  to  be 
loaded  anywhere  in  available  memory  and  appear  to  be  located  at  absolute  zero.  The 
MAC  also  provides  memory  protection  that  prohibits  a  user  from  accessing  memory 
outside  of  the  task's  memory  partition.  With  the  features  described  above  not 
available  in  an  executive  task,  much  care  must  be  exercised  in  writing  such  a  task 
so  that  it  does  not  vector  out  of  its  valid  memory  area  and  destroy  part  of  the 
operating  system  software. 

The  monitor  control  task,  depending  on  options  specified  by  a  pilot,  would  assemble 
the  appropriate  command  that  will  cause  the  proper  audio  linkage  to  be  established 
when  executed  by  the  crosspoint  controller.  This  command  is  sent  via  an  SVC  6 
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communication  from  the  monitor  control  task  to  the  crosspoint  control  task,  at 
which  time  the  command  is  executed  by  the  controller  and  the  audio  link  is 
established.  When  the  pilot  is  finished  using  this  system  utility,  the  monitor 
task  sends  a  disconnect  command  to  the  crosspoint  control  task  which  in  turn,  talks 
to  the  crosspoint  controller  and  the  audio  link  between  the  pilot's  phone  line  and 
the  utility  is  broken.  In  this  manner,  audio  linkages  can  be  established  and 
broken  from  any  phone  line  to  any  utility  in  the  system,  depending  on  the  pilot's 
utilization  of  the  system. 

UTTERANCE  RECOGNITION  DEVICE  (URD)  RESPONSE  TASK.  The  URD  response  task  is 
responsible  for  receiving  the  communications  from  the  URD.  Among  the  types  of 
communications  encountered  on  the  RS-232  asynchronous  line  chat  the  task  is 
monitoring  from  the  URD  are  answers  to  interpret  commands  and  acknowledgements  to 
commands  sent  to  the  URD  via  the  monitor  control  task;  i.e.,  connects,  disconnects, 
and  interprets. 

The  URD  response  task  has  the  highest  priority  of  any  task  in  the  system.  The 
reason  for  this  high  priority  is  to  assure  immediate  response  to  the  completion  of 
a  message  from  the  URD  and  execute  another  read  operation  on  che  asynchronous  line 
as  expeditiously  as  possible.  This  immediate  action  is  required  to  avoid  the 
possibility  of  a  lost  or  broken  message  from  the  URD.  The  reason  this  possibility 
exists  is  because  as  the  system  becomes  fully  utilized,  the  computer  has  less  free 
time  and  the  monitoring  of  the  RS-232  line  from  the  URD  could  degrade  appreciably 
as  the  computer  is  servicing  the  20-voice  lines  with  data.  Since  the  monitor 
control  task  is  sending  commands  to  the  eigh t-channel  device  and  the  computer  and 
device  are  operating  asynchronously  with  respect  to  each  other,  messages  accumulate 
in  a  message  queue  list  in  the  device  pending  transmission  to  the  computer.  Since 
the  list  capacity  is  small,  it  is  seen  that  unless  timely  service  is  given  che 
communication  line,  a  message  overflow  condition  exists  which  would  result  in  lost 
or  garbled  messages.  This  condition  would  be  highly  undesirable,  since  system 
flows  depends  on  these  answers  to  service  the  pilot. 

The  result  of  this  phenomenon  would  be  that  the  pilot  would  become  hung-up  in  the 
system  along  with  system  resources  involved  in  this  transaction  being  suspended 
from  further  use  in  the  system.  In  order  to  further  expedite  the  monitoring  of 
this  line,  the  task  makes  no  decisions  on  the  answers  sent  by  the  URD;  but  instead, 
conveys  this  information  to  the  monitor  control  task  which  analyses  the  answer  at  a 
lower  system  priority;  it  can  then  be  interrupted  when  something  of  more  importance 
requires  system  attention.  Using  this  technique,  it  is  hoped  to  minimize  the 
possibility  of  a  message  queue  list  overflow  condition  from  occurring  in  the  URD. 

MONITOR  CONTROL  TASK.  The  monitor  control  task  (MCT)  is  the  controlling  element  of 
the  mass  weather  dissemination  system  exploratory  engineering  model.  This  task  is 
event  driven  and  only  responds  to  system  queues  entered  on  its  task  queue  lisL.  In 
the  following  paragraphs,  a  description  of  the  subfunctions  that  this  task  performs 
are  discussed. 

URD  Communication  Function.  Whenever  the  system  requires  the  recognition  of  a 
spoken  word  from  the  pilot,  the  URD  must  be  utilized  to  accomplish  this  goal. 
Since  the  system  design  specified  servicing  20  phone  lines  simultaneously  and  the 
URD  is  an  8-channel  device,  it  is  evident  that  an  URD  channel  could  not  be  dedi¬ 
cated  to  a  phone  line,  but  that  multiplexing  of  the  8  URD  channels  to  the  20  phone 
1  i  nes  was  necessary.  When  a  voice  board  task  alerts  the  MCT  of  completion  of  a 
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system  question,  it  extracts  the  phone  line  information  from  the  communication 
received  from  the  voice  board  task.  The  MCT  also  maintains  a  record  of  URD  channel 
utilization  and  thus  knows  if  one  is  available. 

If  a  URD  channel  is  available,  the  MCT  changes  the  channel's  status  to  busy 
during  the  duration  of  the  interchange  between  pilot  and  URD.  The  MCT  then 
assembles  a  connect  command  containing  the  information  on  the  phone  line  and  URD 
channel  to  be  connected  in  the  audio  domain.  This  command  is  transmitted  to  the 
URD  via  an  RS-232  line  and  upon  reception  of  this  command,  the  URD  will  perform  the 
appropriate  crosspoint  connection  internally  and  echo  the  command  back  to  the 
system.  This  command  echo  is  utilized  to  assure  that  both  nongarbled  transmission 
was  achieved  and  that  the  appropriate  action  had  been  performed.  If  a  channel  is 
not  available,  the  pilot  is  placed  on  a  wait  list  until  a  URD  channel  becomes 
available.  The  information  placed  in  this  list  contains  both  the  phone  line 
i dent i f icat ion  and  the  question  just  asked  of  the  pilot. 

Upon  reception  of  the  connect  command  echo,  the  MCT  starts  to  assemble  an 
interpret  command.  Since  increased  recognition  ability  is  obtained  if  the  URD  is 
limited  to  a  subset  of  its  total  vocabulary,  the  words  needed  to  obtain  any  system 
service  have  been  broken  down  into  these  smaller  sets;  each  of  which  encompass  all 
the  words  needed  for  that  particular  option.  The  interpret  command  is  then 
assembled  with  the  appropriate  URD  channel  and  subgroup  code  derived  from  the 
question  just  asked  of  the  pilot.  The  URD  will  again  echo  back  this  command . 

One  of  three  possible  responses  can  be  expected  from  the  issuance  of  an 
interpret  command.  Two  of  these  responses  are  the  time-out  and  not  understood 
codes.  Both  of  these  possibilities  are  handled  the  same  way  by  the  MCT,  which  is 
to  tell  the  voice  board  task  to  play  an  appropriate  "repeat  options"  question  along 
with  an  explanatory  statement  that  the  computer  did  not  understand  him  and  to 
please  try  again.  If  this  phenomenon  happens  a  second  time,  the  MCT  tells  the 
appropriate  voice  board  to  play  a  statement  indicating  that  the  computer  cannot 
understand  the  pilot  and  to  standby  for  a  specialist  who  will  assist  him  with  his 
call.  The  last  possible  response  is  the  answer  to  the  question  played  to  the 
pilot.  The  MCT  can  then  take  the  appropriate  action,  depending  on  the  answer 
obtained . 

When  either  the  second  time-out/not  understood  codes  or  the  answer  is 
obtained,  the  MCT  assembles  a  disconnect  command  containing  the  appropriate  phone 
line  and  URD  channel  information.  This  command  is  sent  to  the  URD,  at  which  time 
the  URD  internally  does  a  crosspoint  operation  to  disconnect  its  channel  from  the 
phone  line  and  then  echos  the  command  back  to  the  MCT  via  the  system.  The  MCT, 
upon  reception  of  this  disconnect  command  echo,  then  makes  this  URD  channel  avail¬ 
able  for  use  and  checks  to  see  if  any  pilots  are  on  the  wait  list  before  going  into 
a  quiescent  condition.  If  a  pilot  were  on  the  wait  list,  he  would  be  removed  from 
the  list  and  a  connect  command  would  be  assembled  and  sent  to  the  URD  before  the 
task  became  inactive. 

The  MCT  also  maintains  a  list  of  commands  sent  to  the  URD  but  not  yet 
responded  to  by  this  device.  If  the  URD,  for  any  reason,  does  not  understand  a 
command,  it  sends  an  ASCII  question  mark  on  the  RS-232  line  in  response  to  this 
command.  This  means  that  one  of  the  commands  on  the  command  list  has  not  been 
executed,  which  will  result  in  a  "hung-up"  condition  for  one  of  the  pilots  using 
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the  system.  Since  it  would  be  highly  undesirable  to  reissue  commands  that  have 
been  implemented,  a  technique  had  to  be  developed  to  ascertain  which  command  needs 
to  be  sent  again  due  to  either  a  broken  or  garbled  original  transmission. 

Upon  reception  of  a  question  mark  from  the  URD,  an  immediate  transfer  of  all 
the  commands  in  the  command  list  to  a  "bad"  command  list  is  executed,  since  one  of 
these  commands  is  the  one  that  was  not  understood.  As  the  URD  now  sends  echos  of 
other  commands  sent  to  it,  the  MCT  does  a  match  of  this  command  with  commands  on 
both  command  lists.  When  a  match  is  found,  that  command  is  removed  from  the  list, 
and  in  the  case  of  the  "bad"  command  list,  when  one  command  entry  remains,  it  can 
be  removed  from  the  "bad"  command  list  and  reissued  to  the  URD,  since  it  is 
obviously  the  command  that  the  UKD  did  not  receive  properly  on  the  first 
t  ransmi ss ion . 

From  the  above  discussion,  it  is  seen  that  great  care  has  been  exercised  to 
assure  no  Lost  transmission  on  the  RS-232  asynchronous  communication  line  between 
the  URD  and  computer.  This  approach  is  mandatory,  since  system  flow  depends 
completely  on  answers  given  by  the  pilot  in  response  to  system  questions  as 
interpreted  by  the  URD. 

Route-Oriented  Briefing  Function.  When  a  voice  board  communicates  to  the  MCT 
that  it  has  just  completed  playing  the  system  options  question  to  the  pilot,  the 
MCT  goes  through  the  URD  commun icat ion  function  described  above,  pLaeing  the 
"options'*  subgroup  code  in  the  interpret  command.  If  the  answer  is  "briefing,"  the 
MCT  tells  the  voice  board  task  to  disseminate  the  system  question  concerning  what 
routeor ient ed  briefing  the  pilot  would  like.  Another  URD  iteration  is  performed, 
this  time  placing  the  "routes"  subgroup  code  in  the  interpret  command.  When  an 
answer  is  obtained,  for  example,  "north,"  the  MCT  conveys  this  information  to  the 
voice  board  task  at  which  time  the  desired  briefing  is  disseminated  to  the  pilot. 
At  the  conclusion  of  the  briefing,  the  voice  board  task  also  disseminates  a  system 
question  asking  the  pilot  if  the  system  can  be  of  any  further  assistance  to  him. 
After  this  question  is  done,  the  voice  board  task  alerts  the  MCT  of  this  fact  and 
another  URD  iteration  is  performed,  this  time  the  subgroup  code  selected  looks  for 
a  "yes/no"  response.  If  the  answer  is  "yes,"  the  MCT  tells  the  voice  board  task 
to  play  the  "options"  question  to  the  pilot  and  if  the  answer  is  "no,"  the  MCT 
tells  the  voice  board  task  to  play  a  complimentary  closing  statement  to  the 
pilot  and  then  terminate  the  transaction  by  a  phone  line  disconnect.  This  voice 
board  is  then  available  for  use  by  another  pilot  requiring  assistance  from  the 
sys  tern . 

Specialist  Function.  The  specialist  function  is  encountered  by  the  pilot  in 
one  of  two  ways.  He  can  be  handed  off  to  a  specialist  by  the  MCT  if  (1)  the  URD 
has  continued  difficulty  in  understanding  what  he  is  saying,  or  (2)  the  pilot  says 
the  word  "specialist"  at  the  conclusion  of  the  "system  options"  question. 

In  either  case,  the  MCT  follows  the  same  algorithm  to  accomplish  the 
connection  of  the  pilot  to  the  specialist.  The  MCT  maintains  a  record  of  avail¬ 
ability  of  the  four  specialist  positions  contained  within  the  system.  The 
specialist  positions  initially  come  up  in  an  unavailable  state  and  become  available 
when  the  specialist  switches  his  on- l ine/o f f- I i ne  switch  on  his  handset  to  the  on¬ 
line  position.  This  switch  is  constantly  monitored,  thus  allowing  the  specialist 
to  change  the  status  of  his  position  as  mandated  by  his  functional  priorities  in 
the  FSb.  In  the  event  a  specialist  position  is  not  available,  the  pilot  is  put  on 
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a  specialist  wait  list  until  such  time  that  either  a  position  changes  its  status  to 
on-line  or  a  position  becomes  available  at  the  conclusion  of  a  previous  connection 
to  this  position. 

If  a  position  is  available,  the  MCT  issues  a  ring  command  to  that  position  and 
then  monitors  this  position  for  one  of  two  possible  responses.  The  first  possible 
response  is  a  pickup  code  transmitted  from  the  handset  telling  the  MCT  that  the 
specialist  has  picked  up  his  instrument.  Upon  reception  of  this  code,  the  MCT 
assembles  a  command  for  the  crosspoint  control  task  containing  information  of  phone 
line  ident i f icat ion  and  the  available  specialist  position.  The  crosspoint  control 
task  conveys  this  information  to  the  crosspoint  controller  which  performs  the 
operation  that  makes  the  audio  link  between  these  two  system  entities.  The  MCT 
also  changes  the  status  of  this  specialist  position  to  busy  status  conditions 
for  the  duration  of  the  conversation  between  pilot  and  specialist. 

The  second  possibility  is  that  the  specialist  decides  he  has  a  higher  priority 
function  to  perform  and  instead  of  picking  up  his  instrument  he  takes  his  handset 
off-line.  When  the  MCT  receives  this  code  from  the  handset,  it  changes  this 
specialist  position’s  status  to  unavailable  and  Looks  for  an  alternate  position  for 
the  piLot,  who  is  stiLl  waiting  to  be  serviced  by  a  specialist.  If  one  is  found,  a 
ring  command  is  sent  to  that  handset  in  order  to  satisfy  the  pilot's  request.  If 
no  position  is  found,  the  pilot  is  put  on  the  specialist  wait  List  until  one 
becomes  available. 

At  the  conclusion  of  the  conversation  between  pilot  and  specialist,  the 
specialist  has  one  of  two  possible  actions  he  can  perform. 

1.  He  can  hang  up  his  instrument,  which  then  transmits  a  hang-up  code  to  the 
MCT  that  causes  the  task  to  do  a  number  of  operations.  The  MCT  assembles  a  dis¬ 
connect  command  to  be  sent  to  the  crosspoint  control  task  to  break  the  audio  link 
between  the  position  and  phone  line.  It  also  communicates  to  the  voice  board  task 
to  disseminate  the  system  question  pertaining  to  being  of  further  assistance  to  the 
pilot.  FinalLy,  the  MCT  makes  the  position  available  and  checks  to  see  if  any 
pilots  are  on  the  specialist  wait  list  and  if  so,  will  remove  the  pilot  from  the 
wait  list  and  issue  a  ring  command  to  this  now  available  position,  before  becoming 
inac t ive . 

2.  The  second  action  is  to  go  off-line  before  he  hangs  up  his  instrument. 
When  the  MCT  detects  this  condition  it  does  the  following  conditions.  It  still 
issues  a  disconnect  command  to  the  crosspoint  control  task  and  tells  the  voice 
board  task  to  disseminate  the  "further  assistance"  question.  Finally,  it  cuanges 
the  status  of  the  position  to  unavailable  and  then  goes  into  a  wait  state 
cond i c i on . 

The  algorithm  described  above  is  basically  a  software  version  of  an  automatic 
call  director  that  can  be  obtained  from  the  telephone  company.  Incorporated  in  the 
software,  however,  are  some  features  that  would  be  hard  to  get  as  options  on  such  a 
system,  plus  the  increased  adaptability  for  change  gained  in  the  software  approach, 
both  of  which  were  deemed  as  valuable  attributes  to  the  system  design. 

Fast  File  Function.  The  pilot  is  directed  to  the  fast-file  recorder  whenever 
he  says  one  of  the  three  system  options  words,  "file,"  "amend,"  or  "close."  The 
MCT  maintains  a  record  of  availability  of  the  two  fast-file  recorders  incorporated 
in  the  mass  weather  dissemination  system  exploratory  engineering  model. 


After  completion  of  the  "system  options"  question  and  the  appropriate  commands 
have  been  sent  to  the  URD  by  the  MCT  and  the  word  "file"  has  been  interpreted  by 
the  URD  and  sent  back  to  the  MCT,  the  following  actions  are  taken  as  described  in 
the  text  that  follows.  If  neither  of  the  two  fast-file  recorders  are  available, 
the  pilot  is  put  on  a  fast-file  wait  list  until  one  of  the  units  becomes  available. 

If  a  fast-file  recorder  is  available,  the  MCT  will  tell  the  voice  board  task 
to  play  the  system  statement  providing  instructions  on  how  to  use  the  fast-file 
recorder  and  also  assembles  a  command  for  the  crosspoint  control  task  to  establish 
the  audio  link  between  the  system  utility  and  the  pilot’s  phone  line.  At  the 
conclusion  of  the  fast-file  instructions,  the  voice  board  task  alerts  the  MCT  of 
this  fact  and  sends  a  "record"  command  to  the  fast-file  recorder.  The  MCT  changes 
ihis  recorder's  status  to  busy  for  the  duration  of  interchange  between  pilot  and 
system  and  the  task  than  goes  into  a  wait  state  until  one  of  two  possible  responses 
is  returned  from  the  recorder. 

One  possible  response  is  a  "jam"  code.  If  the  MCT  receives  this  code,  it 
changes  the  status  of  that  recorder  to  unavailable  and  assembles  a  command  for  the 
crosspoint  control  task  to  do  an  audio  link  disconnect  between  the  pilot's  phone 
line  and  the  fast-file  recorder.  The  MCT  then  tells  the  voice  board  task  to  play 
the  statement  that  explains  to  the  pilot  that  the  fast-file  recorder  has  jammed  and 
to  standby  for  a  specialist  who  will  assist  him  with  his  filing  of  a  flight  plan. 
The  statement  also  requests  that  the  pilot  alert  the  specialist  to  the  fact  that  a 
recorder  is  iammed  so  that  remedial  action  can  be  taken. 

The  other  possible  response  from  the  recorder  is  a  "record  done"  code  which 
when  received  by  the  MCT  causes  it  to  tell  the  voice  board  task  to  play  the  system 
question,  which  asks  if  the  pilot  would  like  to  review  his  flight  plan.  At  the 
conclusion  of  this  question,  the  MCT  does  a  URD  command  iteration  with  the  yes/no 
subgroup  code  placed  in  the  interpret  command. 

If  the  pilot's  answer  is  "no,"  the  MCT  sends  an  "unseize"  command  to  the 
fast-file  recorder.  This  command  causes  the  recorder  to  write  a  file  mark  on  the 
tape  which  protects  the  flight  plan  preceding  it  from  being  further  accessed  and 
also  causes  the  recorder  to  become  available  for  another  flight  plan.  The  MCT 
assembles  a  command  for  the  crosspoint  control  cask  to  break  the  audio  link  between 
the  two  system  entities  and  also  tells  the  voice  board  task  to  play  the  "further 
assistance"  question  to  the  pilot.  Finally,  before  the  MCT  becomes  quiescent,  it 
checks  to  see  if  any  pilot  is  on  the  fast-file  wait  list  and  if  so,  removes  the 
pilot  from  the  wait  list  and  proceeds  as  described  earlier  when  a  fast-file 
recorder  is  available. 

If  the  pilot's  answer  is  "yes,"  the  MCT  sends  a  "rewi  nd/ pi  ay"  command  to  the 
recorder.  The  recorder  then  rewinds  to  a  file  mark  which  constitutes  this  pilot's 
flight  plan  and  then  plays  the  flight  plan  back  to  the  pilot  on  the  already 
existing  audio  link.  At  the  end  of  this  process,  the  recorder  notifies  the  MCT  of 
the  fact  that  it  is  done,  at  which  time  the  MCT  tells  the  voice  board  task  to 
disseminate  the  system  question  concerning  whether  the  pilot  wishes  to  make  amend¬ 
ments  to  his  flight  plan.  If  the  pilot's  answer  *s  "no,"  a  similar  process,  as 
described  for  a  negative  response  to  reviewing  his  flight  plan,  is  executed. 

If  the  pilot's  answer  is  "yes"  to  this  question,  the  MCT  sends  a  "write  file 
mark"  command  to  the  fast-tile  recorder  to  segregate  the  pilot's  flight  plan  from 
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his  amendments;  this  is  done  in  case  the  pilot  wants  to  review  his  amendments  after 
he  has  entered  them.  The  MCT  also  tells  the  voice  board  task  to  tell  the  pilot  to 
standby  to  speak  his  flight  plan  amendments  immediately  after  the  queue  tone.  At 
the  end  ot  this  statement,  the  MCT  sends  a  "record"  command  to  the  fast-file 
recorder.  When  the  fast-file  recorder  alerts  the  MCT  that  this  process  is  com¬ 
pleted,  the  MCT  tells  the  voice  board  task  to  disseminate  the  question  asking  the 
pil  ot  i f  he  wishes  to  review  his  flight  plan  amendments.  If  the  pilot’s  answer  is 
"no,"  it  is  handled  as  described  above  for  a  negative  response  to  fast-file  review 
questions.  If  the  pilot's  answer  is  "yes,"  it  is  handled  in  the  same  manner  as  an 
affirmative  response  to  making  flight  plan  amendments.  This  procedure  of  making 
amendments  can  be  repeated  until  the  pilot  is  satisfied  with  the  information 
contained  in  his  flighL  plan  and  additional  amendments. 

If  the  pilot  says  "amend,"  the  MCT  algorithm  is  similar  to  the  amend  algorithm 
described  earlier  when  the  pilot  amends  his  flight  plan  immediately  after  speaking 
it.  If  the  pilot  says  "close"  in  response  to  the  "options"  system  question,  the 
access  procedure  that  the  MCT  uses  to  obtain  a  fast-file  recorder  for  the  pilot  is 
the  same  as  described  earlier.  The  main  differences  are  that  the  MCT  tells  the 
voice  board  task  to  play  the  statement  that  the  pilot  may  speak  his  flight  plan 
closure  immediately  after  the  queue  tone  and  no  provisions  are  made  to  allow  the 
pilot  to  review  his  flight  plan  closure.  Instead,  the  MCT  sends  an  "unseize" 
command  to  the  fast-file  recorder,  tells  the  voice  board  task  to  play  Lhe  "further 
assistance"  question  and  sends  a  command  to  the  crosspoint  control  task  to  do  an 
audio  disconnect  between  the  recorder  and  phone  line.  The  MCT  then  changes  the 
recorder's  status  to  available  and  checks  the  fast-file  wait  list  Lo  see  if  any 
pilots  in  the  system  are  waiting  for  a  fast-file  utility.  If  there  is  a  pilot  on 
the  wait  list,  the  MCT  would  remove  the  pilot  from  the  wait  list  and  go  through  the 
necessary  procedures  to  connect  the  pilot  to  this  system  utility. 

CONCLUSIONS 


The  following  major  conclusions  have  been  drawn  as  a  result  of  developing  the  mass 
weather  dissemination  exploratory  engineering  model. 

1.  The  engineering  model  demonstrated  that  synchronous  access  of  a  message  was 
feasible  for  multiple  users  via  use  of  a  fast  retrieval  storage  device  (fixed  head 
discs)  and  a  minicomputer. 

2.  The  model  showed  that  me ssage-t o- 1 i ne  multiplexing  was  aehieveable  by  using  an 
untrained  utterance  recognition  device  (URD)  and  a  processor  to  take  appropriate 
action  on  the  answers  obtained  from  the  recognition  device. 

3.  It  was  shown  that  timely  message  segment  updating  was  possible  with  no 
interruption  of  service  to  users  of  the  system. 

4.  The  file  management  technique  developed  and  employed  in  the  system,  induced  the 
minimum  amount  of  overhead  and  obtained  maximum  utilization  of  the  storage  media. 

3.  Timing  measurements  were  made  on  system  overhead  generated  per  audio  output 
channel.  The  experiment  showed  that  approximately  6  percent  of  the  system's  total 
time  was  needed  to  service  an  audio  output  board.  The  experiment  was  done  with 
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eight  audio  output  channels  running  simultaneously.  It  is  seen  from  this  data  chat 
15  channels  could  be  nominally  serviced  simultaneously  by  the  system,  assuming 
linearity  in  system  overhead  per  channel  in  the  ext r apo lat i on  process. 

6.  The  model  proved  that  other  options  could  be  obtained  with  a  one-call  access  of 
the  system.  One  of  these  options  was  the  ability  to  switch  a  caller  to  a  special¬ 
ist  handset  upon  request.  This  was  done  via  use  of  the  URD  and  a  crosspoint  switch 
ar ray /control ler ,  with  the  minicomputer  controlling  these  devices  appropr i at e ly ,  by 
utterance  of  the  word  "special i stM  from  the  caller. 

7.  It  was  shown  that  a  software  counterpart  of  a  hardware  automatic  call 
distributor  functioned  well  in  the  engineering  model.  Along  with  the  ability  of  a 
ring-down  feature  for  an  available  handset,  the  specialist  also  had  the  capability 
to  go  off-line,  upon  reception  of  a  ring  condition,  if  a  more  urgent  task  was 
pending.  The  system,  sensing  this  condition,  would  find  the  caller  another  avail¬ 
able  position,  or  if  none  were  found  would  put  the  caller  on  a  wait  list  until  a 
position  became  available. 

8.  A  final  option  available  to  the  caller  upon  request  is  the  ability  to  file  a 
flight  plan  on  a  digitally  controlled  analog  tape  recorder.  By  speaking  one  of  the 
words  "file,"  "amend,"  or  "close,"  the  system  swi tches  the  pilot's  audio  line  to  an 
available  fast-file  recorder,  via  the  crosspoint  switch  array /cent ro 1 ler .  The 
pilot  also  has  the  choice  of  reviewing  any  information  he  has  entered  on  the 
recorder,  for  content  clarity  and  validity.  The  advantage  of  this  option  is  to 
provide  expeditious  service  to  the  pilot  and  off-load  the  specialist  during  peak 
loading  times  of  the  system. 

9.  System  startup  and  diagnostics  are  one-word  entries  at  the  command  console. 
This  feature  is  available  because  of  the  power  embedded  in  the  operational  software 
of  the  system.  One  of  these  features  is  a  command  substitution  system  (CSS)  which 
executes  multiple  system  commands  by  entry  of  a  one-word  command.  This  feature 
allows  for  nonspecial i zed  personnel  to  run  and  support  the  system,  unless  a  severe 
hardware  malfunction  occurs. 


RECOMMENDATIONS 


The  following  recommenda t ions ,  if  implemented,  are  presented  in  the  following  order 
of  priority. 

1.  A  field  test  and  evaluation  of  the  system  should  be  conducted  to  obtain  data  in 
the  following  question  areas; 

a.  Does  the  system  provide  an  improved  message  product  to  the  pilot? 

d.  Are  the  message  products,  presented  to  the  caller,  representative  of  the 
most  current  information  available? 

c.  What  is  the  utilization  of  the  two  new  options  available  to  the  pilot  in 
the  system;  i.e.,  specialist  and  fast-file? 

d.  Is  the  pilot  provided  timely  service  in  all  areas  of  system  utilization? 
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Is  the  specialist's  workload  reduced  significantly  by  the  advent  of  the 


e . 

system? 

f.  Is  the  caller's  line-hold  time  reduced  appreciably  for  a  total  transaction 
with  the  system;  i.e.,  obtain  the  pertinent  information  for  making  a  go/no  go 
decision  for  a  flight  and  if  a  decision  is  made  to  fly,  filing  a  flight  plan? 

g.  Does  the  system  provide  enough  information  and  assistance  for  the  pilot  to 
decide  on  making  a  flight? 

h.  What  is  the  general  aviation  publics'  feelings  on  the  system  overall? 

2.  The  latest  revision  of  the  multitasking  operating  system  should  be  incorporated 
into  the  system.  A  substantial  amount  of  time  savings  in  the  input/output  (1/0) 
overhead  has  been  achieved  in  this  current  level  of  the  operating  system.  The 
figures  for  the  reduction  in  I/O  overhead  announced  in  the  new  operating  system 
indicate  that  20  audio  output  channels,  an  increase  of  33  percent  over  the  current 
capacity,  could  then  be  supported  by  the  system. 

3.  An  investigation  into  concatenation  of  weather  messages  at  the  word  level 
should  be  conducted.  This  would  involve  the  development  of  the  software  tools 
necessary  to  produce  a  vocabulary  disc  and  retrieval  of  words  from  this  disc  to  be 
strung  together  to  form  intelligible  sentences.  The  vocabulary  disc  would  contain 
the  compendium  of  words  necessary  to  produce  any  weather  message  product. 

The  main  advantage  to  concatenation  at  the  word  level  is  a  vast  savings  in  storage 
over  the  technique  involved  in  phrase  level  concatenation,  where  words  have  to  be 
stored  multiple  times  in  different  phrases.  Another  advantage  gained  by  concaten¬ 
ation  at  the  word  level  is  less  restraints  are  placed  on  the  message  originator  in 
formatting  a  weather  message  product.  A  message  can  be  generated  in  free  text  with 
the  only  constraint  being  that  the  word  be  a  viable  entry  on  the  vocabulary  disc. 

The  major  benefit  of  this  technique  is  a  substantial  savings  in  manpower.  This  is 
demonstrated  by  the  fact  that  a  message  can  be  generated  textually  at  a  central 
location;  transmitted  in  an  ASCII  mode  to  a  remote  site  where  it  is  concatenated 
and  disseminated  automatically,  as  in  a  Transcribed  Weather  Broadcast  (TWEB) 
transmission  outlet. 


46 


